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Abstract 


This document defines a Dynamic Host Configuration Protocol (DHCP) 
option that will be used to configure various devices deployed within 
CableLabs architectures. Specifically, the document describes DHCP 
option content that will be used to configure one class of CableLabs 
client device: a PacketCable Media Terminal Adapter (MTA). The 
option content defined within this document will be extended as 
future CableLabs client devices are developed. 
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1. Conventions used in this document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 [1]. 
2. Terminology 
Definitions of terms used throughout this document: 


* "Telephony Service Provider" or "TSP" 


The business entity from which a subscriber receives telephony 
service. 


See RFC 2131 [6] for additional DHCP terminology. 
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Introduction 


Cable Television Laboratories, Inc. (CableLabs) is a non-profit 
research and development consortium that serves the cable television 
industry via design and specification of new and emerging broadband 
service architectures. Several CableLabs initiatives define DHCP 
clients that have specific DHCP configuration requirements. One such 
initiative is the PacketCable project. 


The PacketCable project is aimed at architecting, qualifying, and 
supporting Internet-based multimedia services over cable-based packet 
networks. These new multimedia services will include telephony and 
videoconferencing, delivered using the basic Internet Protocol (IP) 
technology that is used to send data via the Internet. 


PacketCable 1.0 provides Voice over IP (VoIP) service delivery. The 
VoIP service is supported at the customer site by two key components: 
a Cable Modem (CM) and a Media Terminal Adapter (MTA). The CM 
converts the cable RF signals to/from various IP voice protocols, 
while the MTA converts the VoIP protocols into analog telephony 
compatible with a common telephone. 


The CM and MTA may be packaged together or separately. If packaged 
together, the unit is referred to as an Embedded-MTA (EMTA - depicted 
in Figure 1). If packaged separately, the MTA is referred to as a 
Standalone MTA (SMTA). 


Telephony | Media | internal | Cable | RF Link 
Link 


| | 
| | 
| | 
aN eee |---| Terminal |===========| Modem | ---- | ------- 
| | 


Figure 1. PacketCable 1.0 Embedded-MTA 


The CM and MTA are distinct IP devices: each has its own MAC address 
and IP configuration. The CM and MTA utilize the DHCP protocol to 
obtain IP configuration. It is assumed that the CM and MTA may be 
administered by different business entities. The CM communicates 
with and is configured by the Data Access Provider’s (DAP’s) DHCP 
servers. Likewise, the MTA communicates with and is configured by 
the Telephony Service Provider’s (TSP’s) DHCP servers. 
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The PacketCable architecture requires that the business entity 
controlling the configuration of the CM also determines which 
business entities control the configuration of the MTA. This is 
similar to the example found in the PSTN system: individuals can pick 
their long distance carriers even though the ultimate control of 
their telephone remains with the local carrier. 


Due to specific needs of the MTA configuration process (described in 
[7]), a new CableLabs Client Configuration (CCC) option is needed for 
the DHCP protocol. Both CM and MTA DHCP clients will request this 
option. When requested, both the DAP and TSP DHCP servers will 
populate this option into DHCP responses. See section 6 for further 
operational details. 


It should be noted that, although the CCC option will be initially 
deployed to support PacketCable VOIP applications, the CCC option 


will also be used to support various non VOIP applications. Use of 
the CCC option does not necessarily mean that the service provider is 
a TSP. 


4. CableLabs Client Configuration Option Format 


The option begins with a tag octet containing the option code (code 
122). A length octet follows the tag octet. The value of the length 
octet does not include itself or the tag octet. The length octet is 
followed by "length" octets of sub-option content (total length, not 
sub-option count). The option layout is depicted below: 


When the total length of a CCC option exceeds 255 octets, the 
procedure outlined in [4] MUST be employed to split the option into 
multiple, smaller options. 


A sub-option begins with a tag octet containing the sub-option code. 
A length octet follows the tag octet. The value of the length octet 
does not include itself or the tag octet. The length octet is 
followed by "length" octets of sub-option information. The sub- 
option layout is depicted below: 


4+------------------- 4+-------- 4+------------------------ + 


| Sub-option Code | Length | Sub-option information 
RR +-------- D A + 
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The sub-option codes are summarized below. 


fae oS +--------- eS Seo ee Oe ee oe ee ee ee ees + 
| Sub- | Sent to | Description 

| option | | | 
| Code | | | 
+ + + 
| if | CM | TSP’s Primary DHCP Server Address | 
+--------- +--------- pa a eee eee ee ee + 
| 2 | cM | TSP’s Secondary DHCP Server Address 
+--------- pas SSS $e SSH SSS Se ae Se nS Seo see aes ae + 
| 3 | MTA | TSP’s Provisioning Server Address 

e nE E pemean ha ee nE R + 
| 4 | MTA | TSP’s AS-REQ/AS-REP Backoff and Retry | 
+--------- +--------- pe eS a ee Se ee eae + 
| 5 | MTA | TSP’s AP-REQ/AP-REP Backoff and Retry | 
4+--------- E AA $------------------ a 55-55 ------- + 
| 6 | MTA | TSP’s Kerberos Realm Name 

peiie +--------- 4----------- 5-55-55 5-5-5 5-5-5 ------------ + 
| 7 | MTA | TSP’s Ticket Granting Server Utilization | 
panene E P a a E 5-55 ------- + 
| 8 | MTA | TSP’s Provisioning Timer Value 

D an Phaea SSeS SE SS ae Se SS ees Ss saesS + 
| 9 - 255 | | Reserved for future extensions 

Sea +--------- Poe a e a a a i E + 


5. CableLabs Client Configuration Option: Sub-Option Definitions 


The following sections provide detailed descriptions of each sub- 
option. There are a few general formatting rules: 


- Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 
[3] section 3.1. Note that a terminating 0 is required. Also 
note that compression, as described in RFC 1035 [3] section 4.1.4, 
MUST NOT be applied. 


-— IPv4 addresses MUST be encoded as 4 binary octets in network 
byte-order (high order byte first). 


- All multi-octet quantities MUST be encoded per network byte- 
ordering. 


5.1. TSP’s DHCP Server Address Sub-Options 
The TSP DHCP Server Address sub-options identify the DHCP servers 
from which an MTA is permitted to accept a DHCP OFFER. Sub-option 1 


is the address of the TSP’s primary DHCP server. Sub-option 2 is the 
address of the TSP’s secondary DHCP server. 
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The sub-option length MUST be 4 and the sub-option MUST include the 
DHCP server’s IPv4 address as follows: 


Code Len Address 
+----- +----- +----- +----- +----- +----- + 
| 1/2 | 4 | al | a2 | a3 | aa | 
+----- +----- +----- +----- +----- +----- + 


5.2. TSP’s Provisioning Server Address Sub-Option 


This option contains the address of the TSP’s Provisioning server. 
MTAs communicate with the Provisioning server at various stages in 
their provisioning process. 


The address can be configured as either an IPv4 address or as an 
FQDN. The encoding of sub-option 3 will adhere to one of 2 formats. 


1. IPv4 address. The sub-option length MUST be 5. The length octet 
MUST be followed by a single octet that indicates the specific 
address type that follows. This type octet MUST be set to 1 to 
indicate an IPv4 address. The type octet MUST be followed by 4 
octets of IPv4 address: 


Code Len Type Address 

+----- +----- +----- +----- +----- +----- +----- + 
ft et rab Als ll, we a, aa ae) aa] 
+----- +----- +----- +----- +----- +----- +----- + 


2. FQDN. The length octet MUST be followed by a single octet that 
indicates the specific address type that follows. This type octet 
MUST be set to 0 to indicate an FQDN. The type octet MUST be 
followed by the encoded FQDN: 


Code Len Type FQDN 

4+----- +----- 4+----- +----- 4+----- + 4+----- + 
e §]) ane ||) Oe | ea ee | | fn | 
4+----- 4+----- 4+----- 4+----- 4+----- + 4+----- + 


It is not anticipated that additional type codes, beyond IPv4 (1) and 
FQDN (0), will be required. Thus, IANA will not be required to 
maintain a registry of type codes. 


5.3. TSP’s AS-REQ/AS-REP Backoff and Retry 


This sub-option configures an MTA’s Kerberos AS-REQ/AS-REP timeout, 
backoff, and retry mechanism. 
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RFC 1510 [5] does not define a backoff/retry mechanism to be employed 
when an AS-REQ/AS-REP message exchange fails. This sub-option 
contains parameters required by the backoff/retry mechanism outlined 
in [8]. 


The encoding of this sub-option is depicted below: 


Code Len Nom Timeout Max Timeout Max Retries 

4+---+---4---4---+---+4---4---4---+---4+---4+---4+---+---4+---4+ 
| 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 Eai |r2 | r3 |r4 | 
4+---+---4---4+---+---+4---4---4+---+---4+---4+---4+---+---4+---4+ 


The length octet of this sub-option MUST contain the value 12. 


The length octet MUST be followed by 4 octets containing the AS- 
REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit 
unsigned quantity in units of milliseconds. 


The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout 
value. This value is a 32 bit unsigned quantity in units of seconds. 


The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry 
count. This value is a 32 bit unsigned quantity. 


5.4. TSP’s AP-REQ/AP-REP Backoff and Retry 


This sub-option configures an MTA’s Kerberos AP-REQ/AP-REP timeout, 
backoff, and retry mechanism. 


RFC 1510 [5] does not define a backoff/retry mechanism to be employed 
when an AP-REQ/AP-REP message exchange fails. This sub-option 
contains parameters required by the backoff/retry mechanism outlined 
in [8]. 


The encoding of this sub-option is depicted below: 
Code Len Nom Timeout Max Timeout Max Retries 
+---4+---4+---+4---+4---+4+---+---+---4+---4+---4+---4+---4+---4---+ 
| 5 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 | r3 |r4 | 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 
The length octet of this sub-option MUST contain the value 12. 
The length octet MUST be followed by 4 octets containing the AP- 


REQ/AP-REP nominal (initial) timeout value. This value is a 32 bit 
unsigned quantity in units of seconds. 
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The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout 
value. This value is a 32 bit unsigned quantity in units of seconds. 


The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry 
count. This value is a 32 bit unsigned quantity. 


5.5. TSP’s Kerberos Realm Name Sub-Option 
The PacketCable architecture requires an MTA to authenticate itself 
to the TSP’s network via the Kerberos protocol. A Kerberos Realm 
name is required at the MTA to permit a DNS lookup for the address of 


the TSP’s Kerberos Key Distribution Center (KDC) entity. 


The Kerberos Realm name MUST be encoded per the domain style realm 


name described in RFC 1510 [5]. This realm name MUST be all capital 
letters and conform to the syntax described in RFC 1035 [3] section 
3.1. The sub-option is encoded as follows: 


Code Len Kerberos Realm Name 


5.6. TSP’s Ticket Granting Server Utilization Sub-Option 


This sub-option encodes a boolean value which indicates whether an 
MTA should or should not utilize a TGT (Ticket Granting Ticket) when 
obtaining a service ticket for one of the PacketCable application 
servers. The encoding is as follows: 


The length MUST be 1. The last octet contains a Boolean value which 
MUST be either 0 or 1. A value of 1 MUST be interpreted as true. A 
value of 0 MUST be interpreted as false. 


5.7. TSP’s Provisioning Timer Sub-Option 
The provisioning timer defines the maximum time allowed for the MTA 
provisioning process to complete. If this timer expires before the 


MTA has completed the provisioning process, the MTA should reset the 
timer and re-start its provisioning process from the beginning. 
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6. 


The sub-option length MUST be 1. The value octet specifies 0 to 255 
minutes. A value of 0 means the timer MUST be disabled. 


Informational Description of CCC Option Usage. 


Cablelabs client devices issue DHCP requests that include DHCP 
options 55 (Parameter Request List) and 60 (Vendor Class Identifier). 
Option 55 will request the CCC option from the DHCP server. Option 
60 will indicate the specific Cablelabs client device type, thus 
directing the DHCP server to populate specific CCC sub-option content 
in its responses. The details of which CCC sub-options are populated 
for each specific client type are specified in various Cablelabs 
project specifications. For example, specific usage of the CCC 
option for the PacketCable project is described in [7]. 


Note that client devices never populate the CCC option in their DHCP 
requests. 


IANA Considerations 


IANA has assigned a value of 122 for the DHCP option code described 
in this document. 


Legacy Use Information 


The CableLabs Client Configuration option initially used the site- 
specific option value of 177 (0xB1). The use of the site-specific 
option is to be deprecated now that IANA has issued an official 
option number. 


Procedure for Adding Additional Sub-options 


IANA is requested to maintain a new number space of "CableLabs Client 
Configuration Sub-options", located in the BOOTP-DHCP Parameters 
Registry (http://www.iana.org/assignments/bootp-dhcp-parameters). 

The initial sub-option codes are described in section 4 of this 
document. 


IANA is requested to register codes for future CableLabs Client 
Configuration Sub-options via an "IETF Consensus" approval policy as 
described in RFC 2434 [2]. 
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10. Security Considerations 


Potential exposures to attack in the DHCP protocol are discussed in 
section 7 of the DHCP protocol specification [6] and in 
Authentication for DHCP Messages [9]. 


The CCC option can be used to misdirect network traffic by providing 
incorrect DHCP server addresses, incorrect provisioning server 
addresses, and incorrect Kerberos realm names to a Cablelabs client 
device. This misdirection can lead to several threat scenarios. A 
Denial of Service (DoS) attack can result from address information 
being simply invalid. A man-in-the-middle attack can be mounted by 
providing addresses to a potential snooper. A malicious TSP can 
steal customers from the customer selected TSP, by altering the 
Kerberos realm designation. 


These threats are mitigated by several factors. 


Within the cable delivery architecture required by PacketCable, the 
DHCP client is connected to a network through a cable modem and the 
CMTS (head-end). The CMTS is explicitly configured with a set of 
DHCP servers to which DHCP requests are forwarded. Further, a 
correctly configured CMTS will only allow downstream traffic from 
specific IP addresses/ranges. 


Assuming that server addresses and Kerberos realm name were 
successfully spoofed to the point that a malicious client device was 
able to contact a KDC, the client device must still present valid 
certificates to the KDC before being service enabled. Given the 
computational overhead of the certificate validation process, this 
situation could present a DoS opportunity. 


Finally, it is possible for a malicious (although certified) TSP to 


redirect a customer from the customer’s selected TSP. It is assumed 
that all TSP’s permitted onto an access providers network are trusted 
entities that will cooperate to insure peaceful coexistence. If a 


TSP is found to be redirecting customers, this should be handled as 
an administrative matter between the access provider and the TSP. 
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14. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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